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DETAILED ACTION 



Continued Examination Under 37 CFR LI 14 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 15 September 2005 has been entered. 

2. This action is responsive to Applicant's amendment dated 15 September 2005, 
responding to the 3 June 2005 Office action provided in the rejection of claims 1-26, wherein 
claims 1, 1 1, 17, 22, and 24 have been amended, no claims have been canceled, and no new 
claims have been added. Claims 1-26 remain pending in the application and have been fully 
considered by the examiner. 



Response to Arguments 

3. Applicant suggests in page 7 of the response, that prior drawing objections (Final Action 
mailed 6/3/05) are obviated by claim amendments. However, the limitations cited in the 
previous drawing objection are still present in the claims. The objection is maintained, and a 
further explanation is provided in the Drawings section below. 

4. Applicant's arguments, see pages 8-10, filed 9/15/05, with respect to the rejections of 
claims 1-26 under 102(b) have been fully considered and are persuasive. Therefore, the rejection 
has been withdrawn. However, upon further consideration, a new ground of rejection is made in 
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view of U.S. Patent 5,295,222 to Wadhwa et al. (hereinafter "Wadhwa") and U.S. Patent 
6,332,163 to Bowman- Amuah. 

5. On page 10, paragraph 1 of the response, Applicant argues that the present invention 
allows alterations to be made without significant supplementary programming. These arguments 
appear to be related to claim elements appearing in amended claims 1 1 and 17. It is noted that 
Applicant has not particularly pointed out where in the originally filed specification these new 
limitations find support. 

Drawings 

6. The drawings are objected to under 37 CFR 1 .83(a). The drawings must show every 
feature of the invention specified in the claims. Therefore, the decoupled mobile data model 
(claims 1, 1 1, 17, 22, and 24), a mobile data model "operable to enable changes in data structure 
and data handling without requiring programmatic changes" (claim 1 1), the "changes to the 
mobile data model <that> effect changes in system data descriptions and rules governing data 
handling without requiring programmatic changes in applications included in an enterprise back- 
end device" (claim 17), and the "mobile data model decoupled from a particular client interface 
and enterprise data source" (claim 24) must be shown or the feature(s) canceled from the 
claim(s). While the drawings show a data model (Figures 12, 13, etc.), they do not show a 
decoupled data model. In particular, claims 1, 1 1, 17, and 22 describe a mobile data model in 
terms of it being "independent". Claim 24 describes decoupling in terms of "a particular client 
interface and enterprise data source". Particularly with respect to Applicant's arguments (page 9 
paragraphs 1, 3) that Wright does not teach a decoupled mobile data model that is "defined 
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explicitly and separately from client programs", such claim limitations that define the instant 
invention over the prior art should be illustrated. None of the drawings show such features of a 
mobile data model. No new matter should be entered. 

Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to 
the Office action to avoid abandonment of the application. Any amended replacement drawing 
sheet should include all of the figures appearing on the immediate prior version of the sheet, 
even if only one figure is being amended. The figure or figure number of an amended drawing 
should not be labeled as "amended." If a drawing figure is to be canceled, the appropriate figure 
must be removed from the replacement sheet, and where necessary, the remaining figures must 
be renumbered and appropriate changes made to the brief description of the several views of the 
drawings for consistency. Additional replacement sheets may be necessary to show the 
renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an 
application must be labeled in the top margin as either "Replacement Sheet" or "New Sheet" 
pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will 
be notified and informed of any required corrective action in the next Office action. The 
objection to the drawings will not be held in abeyance. 

Claim Rejections - 35 USC § 112 
' 7. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 
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8. Claims 11-21 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with 
the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. 

9. Claim 1 1 recites ". . .wherein the mobile data model is . . . operable to enable changes in 
data structure and data handling without requiring programmatic changes in the enterprise back 
end. . ." However, the originally filed specification does not provide support for these 
limitations. In contrast, page 16 line 16 - page 17 line 3 recites: 

Once a mobile data model has been built, the developer can build one or more software program 
components that will operate on the server side of the mobile computing system in order to 
integrate the mobile computing system with one or more enterprise back-end applications, at step 
416. These components, or software instances, may be built using a variety of programming 
languages, depending on the systems in question. These components may facilitate the transfer of 
data to and from enterprise systems as application requirements dictate. Each integration 
component may access application programming interfaces (APIs) provided by the mobile 
computing system in order to access a desired information instances. As application requirements 
change, the developer may enhance the integration components as needed. 

This paragraph appears to teach that a mobile data model is built before server or integration 
components can be built, and that if requirements change, the integration components may be 
changed. If this interpretation is correct, then it would be the integration components that 
"enable changes", not the mobile data model as recited in claim 11. Further description is found 
on page 34 line 14 - page 35 line 2: 

As mentioned above, there may be three phases a developer will complete when developing a 
mobile domain solution; (1) create a mobile data model that may allow instantiation of a domain 
data store and a mobile data store; (2) write an integration component that facilitates 
communication between a domain data store and a back-end application; and (3) write a client- 
side or mobile device bound mobile application that support interaction between a mobile data 
store and a user. In effect, the mobile data model may provide a layer of abstraction between a 
back-end database and a mobile application. As such, an integration component may access a 
domain data store instantiated from a mobile data model or a portion thereof, and a mobile 
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applications may access a mobile data store instantiated from the same mobile data model or a 
portion thereof on an individual hand-held device. 

According to this passage, the mobile data model itself does not appear to be "operable" as 
recited in claim 1 1 . Rather, the mobile data model allows an instantiation in the form of a data 
store that would then interface with an integration component (item 2 above) or a mobile 
application (item 3 above). Any change in the data model would likely require a new 
instantiation of the data store, and it would seem that any change in the data store would further 
require modification to any associated integration components or applications. However, the 
specification appears to be silent in regards to the ability to change the mobile data model 
without requiring programmatic changes as recited in the claim. 

10. Claims 12-16 are rejected as being dependent upon a rejected base claim. 

11. Claim 17 contains recites . .changes to the mobile data model effect changes in system 
data descriptions and rules governing data handling without requiring programmatic changes in 
applications included in an enterprise back-end or mobile device." However, as addressed in the 
above rejection of claim 1 1, the specification appears to be silent on the requirements of 
programmatic changes in response to changes to the mobile data model. Further the 
specification does not expressly recite "data descriptions" or "rules governing data handling", 
and applicant has not particularly pointed out where these limitations find support in the 
originally filed specification. Reference to "Fields" used "to describe attributes" is found on 
page 29 lines 19-20. However, these field descriptions used in the data model do not appear to 
affect any such "system data descriptions". Further, while the specification refers to "rules in the 
system dictate" (page 13 lines 19-21, and page 13 lines 1-4), reference to "rules governing data 
handling", as recited in the claim, was not found in the specification. Page 24 line 7 also refers 
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to a "rules-processing engine". This engine appears to respond to transactions, but the 
specification does not mention any change in the rules engine in direct response to a change in 
the mobile data model. 

12. Claims 18-21 are rejected as being dependent upon a rejected base claim. 

13. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

14. Claims 1 1-21 are rejected under 35 U.S.C. 1 12, second paragraph, as failing to set forth 
the subject matter which Applicants regard as their invention. Evidence that claims 11-21 fail to 
correspond in scope with that which Applicants regard as the invention can be found in the reply 
filed 9/15/05. On page 10, paragraph 1 of the response, Applicant argues that the present 
invention allows alterations to be made "without significant supplementary programming". 
However, claim 1 1 recites "without requiring programmatic changes in the enterprise back end". 
These two statements appear to conflict. The phrase "without significant supplementary 
programming" implies that some amount of supplementary programming is required, but the 
claim language says that no supplementary programming is required. In light of Applicant's 
comments, it is not clear if any supplementary programming would or would not be required, 
and the originally filed specification does not appear to address the issue. Claim 17 contains 
language similar to claim 1 1, and is rejected for the same reasons. Claims 12-16 and 18-21 are 
rejected as being dependent upon a rejected base claim. 
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Claim Rejections - 35 USC § 103 

1 5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

16. Claims 1-26 are rejected under 35 U.S.C. 103(a) as being unpatentable over prior art of 
record U.S. Patent 5,857,201 to Wright et al. (hereinafter referred to as "Wright") in view of U.S. 
Patent 5,295,222 to Wadhwa et al. (hereinafter "Wadhwa") in view of U.S. Patent 6,332,163 to 
Bowman- Amuah (hereinafter "Bowman- Amuah"). 

As per claim 1, Wright discloses: 

A method for use of a software application (column 13 line 1 - column 14 line 
1 5), the method comprising: 

creating a mobile data model, the mobile data model ... required by a mobile 

application See column 5 lines 49-52: 

The FL Engine 160 incorporates a full local database implementation that allows data to 
be manipulated and collected by the FL client while not connected to the FL server 132. 

instantiating at least a portion of the mobile data model to create a mobile data 

store containing enterprise information column 2 lines 24-26: 

The client/server (C/S) architecture of the present invention is designed to allow the 
client to become a direct extension of the corporate data sources. 

also column 2 lines 50-58: 

. . .in a computer network, including a server, a data source, and a mobile client having a 
database, a method of synchronizing the client database and data source during a non- 
persistent connection, the method comprising the steps of connecting the mobile client to 
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the server; manipulating the client database by the server; updating the data source 
responsive to the manipulation by the server; and disconnecting the client from the 
server. 

creating one or more mobile software applications to interact with the mobile 

data store column 2 lines 34-38: 

Applications built with existing development tools can be enabled to either exchange 
data on demand, or provide facilities for a multi-port server allowing remote database 
access and e-mail access from the field. 

making the mobile software application and at least a portion of the mobile data 
model available to a consumer In Wright, a consumer can be considered a PDA, which 
functions as the client in the client/server architecture disclosed. As such, the application 
and data model are inherent to the function of the system, since without availability to 
them, the system loses its primary functionality. 

Wright also does not expressly disclose a data model explicitly describing one or 

more data elements, data relationships, data dependencies and data distribution 

attributes wherein the mobile data model is an independent entity... However, in an 

analogous environment, Wadhwa teaches that an independent data model that defines at 

least data relationships can be used for generation and distribution of applications. See 

column 6 lines 59-63: 

An association between entities is known as a relationship. For example in FIG. 3 the 
entity, Organization 1, is now linked to the entity, Employee, by the relationship, 
Employs 3. Relationships are also defined by attributes. 

Applicant's use of alternative language in the claim, i.e. "one or more" allows Wadhwa 
to teach this claim limitation with the above cited data relationship attributes. It would 
have been obvious to one of ordinary skill in the art at the time the invention was made to 
use Wadhwa's data model including data relationship attributes with Wright's software 
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platform. One of ordinary skill would have been motivated to provide a data model that 

can be readily re-used in subsequent applications (Wadhwa column 7 lines 16-18). 

Wright does not expressly disclose wherein the mobile data model is ...decoupled 

from a particular interface and enterprise data source. However, in an analogous 

environment, Bowman- Amuah teaches that it is important to decouple a data model. See 

Bowman- Amuah column 236 lines 51-56 

Many additional factors influence the detailed design of this communication mechanism. 
Some systems support volatile and constantly changing object models, data models and 
data structures. In these systems, flexible, de-coupled communication is extremely 
important. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to use Bowman- Amuah's teaching of a decoupled data model with Wadhwa's 
independent data model. One of ordinary skill would have been motivated to use a 
shared format that decouples the model in order to efficiently handle changes to the 
system (Bowman-Amuah column 237 lines 7-9). 

As per claim 2, the above rejection of claim 1 is incorporated. Wright further 
discloses: wherein the consumer comprises a distributed computing device (column 2 
lines 38-42). 

As per claim 3, the above rejection of claim 1 is incorporated. Wright further 
discloses: initiating deployment of the mobile software application and the at least a 
portion of the mobile data model to a plurality of distributed computing devices (column 
2 lines 32-34). 
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As per claim 4, the above rejection of claim 1 is incorporated. Wright further 
discloses: using the mobile data model to create a domain data store in a middle tier 
server (column 2 lines 56-57). 

As per claim 5, the above rejection of claim 1 is incorporated. Wright further 
discloses: wherein a first consumer receiving the mobile software application can access 
and update data instances in the domain data store using the at least a portion of the 
mobile data model (column 4 lines 38-49). 

As per claim 6, the above rejection of claim 1 is incorporated. Wright further 
discloses: wirelessly deploying the mobile software application to a first consumer 
(column 5 lines 40-41; also column 4 lines 2-4; also column 11 lines 16-17). 

As per claim 7, the above rejection of claim 1 is incorporated. Wright further 
discloses: developing a distribution rule that identifies a group of consumers; and 
initiating deployment of the mobile software application to the group of consumers 
(column 11 lines 10-17). 

As per claim 8, the above rejection of claim 1 is incorporated. All further 
limitations have been addressed in the above rejections of claims 3, 4, and 5. 
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As per claim 9, the above rejection of claim 1 is incorporated. All further 
limitations have been addressed in the above rejections of claims 2, 3, and 6. 

As per claim 10, the above rejection of claim 9 is incorporated. Wright further 
discloses: wherein the first consumer comprises a group of mobile workers sharing a job 
description (column 4 lines 17-21). 

As per claim 11, Wright discloses: 

A system for application development in a mobile domain (Figure 2), comprising: 
a middle tier server; a domain data store maintained in the middle tier server, the 

domain data store representing enterprise information maintained in an enterprise back 

end column 6 lines 27-33: 

The FormLogic Server 132 serves as a "gateway" between FormLogic Clients (e.g., 136, 
142, 146) and enterprise data sources (e.g., 180, 182). The server 132 supports what is 
known as a multi-tier client/server model in that it creates an intermediate server 
between the client and the "traditional" or "original" server. 

also column 7 lines 45-64: 

A service defines the relationship between a client application and an enterprise data 
source. Examples of services include Mail, World Wide Web Gateway, or Inventory. 
The service instantiations can be considered as interfaces between the "master" service 
and the connection. 

Here, the service instantiations represent enterprise information maintained in an 
enterprise back end, and as such can be interpreted as domain data stores within the 
middle tier server.); 



Application/Control Number: 09/848,770 
Art Unit: 2192 



Page 13 



an application development engine operable to generate instructions that can be 

deployed to the distributed computing platform and that allow the distributed computing 

platform to access information within the mobile data store column 4 lines 2-4: 

Complete Software Distribution interface allowing developers to programmatically install 
FormLogic forms, agents and tables during connections"; also column 4 lines 41-43: 
"This allows portions of databases to be carried into the field where they can be modified 
and later synchronized with the server database."; also column 5 lines 16-17: "The FL 
client 136 includes an FL Engine 160 which allows FormLogic applications to execute 
on a variety of handheld devices"). 

Wright does not expressly disclose a mobile data model ... operable to enable 

changes in data structure and data handling without requiring programmatic changes in 

the enterprise back end However, in an analogous environment, Bowman- Amuah 

teaches that a streamed model can be described using meta-data. See Bowman-Amuah 

column 237 lines 7-13: 

In cases like this, it would be better to implement a communication mechanism or 
"shared format" that can better handle changes to the systems. 

Therefore, use a Self-Describing Stream and create a stream that contains message data 
AND descriptive meta-data. Then use a message language to read the formatting 
information and meta-data off of the stream 

This "Self-Describing Stream" enables changes to a system without requiring 
programmatic changes since the stream provides all the details regarding its contents 
through descriptive meta-data. It would have been obvious to one of ordinary skill in the 
art at the time the invention was made to use Bowman-Amuah' s teaching of a self- 
describing stream with Wadhwa's independent data model. One of ordinary skill would 
have been motivated to use a shared format that permits the efficient handling of changes 
to the system (Bowman-Amuah column 237 lines 7-9). 

All further limitations have been addressed in the above rejection of claim 1. 
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As per claim 12, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: wherein the application development engine is operable to generate object 
oriented instructions (column 5 lines 33-36, referencing U.S. Pat. 5,704,029 [incorrectly 
listed as 5,204,029], shows inherent use of the Newton Script object-oriented language.). 

As per claim 13, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: further comprising a graphical user interface (GUI) engine responsive to the 
application development engine (column 5 lines 30-33). 

As per claim 14, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: a mobile data modeler operable to access the mobile data model (column 5 
lines 33-36: "script engine"); and 

a graphical user interface (GUI) engine operable to present a developer with an 
interface for the mobile data modeler to modify the mobile data model (column 5 lines 
33-36: "user interface"). 

As per claim 15, the above rejection of claim 1 1 is incorporated. Wright further 
discloses: further comprising an enterprise back end system maintaining the enterprise 
information (column 4 lines 65-67). 
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As per claim 16, the above rejection of claim 1 1 is incorporated. All further 
limitations have been addressed in the above rejection of claim 6. 

As per claim 17, Wright discloses: 

a memory associated with the distributed computing platform, the memory storing 
a mobile data store comprising information indicative of information in an enterprise 
backend (column 5 lines 18-20: The Apple MessagePad Model 120 inherently comprises 
memory). 

All further limitations have been addressed in the above rejections of claims 1 and 

11. 

As per claim 18, the above rejection of claim 17 is incorporated. All further 
limitations have been addressed in the above rejection of claim 1. 

As per claim 19, the above rejection of claim 18 is incorporated. Wright further 
discloses: wherein the mobile application comprises user task specific routines (column 6 
lines 46-59). 

As per claim 20, the above rejection of claim 18 is incorporated. Wright further 
discloses: wherein the mobile application comprises user specific routines (column 7 
lines 45-53). 
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As per claim 21, the above rejection of claim 20 is incorporated. Wright further 
discloses: wherein the user specific routines are specific to a first user of the distributed 
computing platform, the system further comprising: a second mobile application that 
comprises a second set of specific routines for a second user of the distributed computing 
platform (column 10 line 66 - column 12 line 19). 

As per claim 22, Wright discloses: 

establishing a first communication link with a mobile computing device; 

disconnecting the first communication link; establishing a second communication link 

with the mobile computing device; and receiving transaction data across the second 

communication link, the transaction data resulting from execution of the client-side 

application by the mobile computing device at least a portion of the execution occurring 

after disconnecting the first communication link and before establishing the second 

communication link column 5 lines 52-58: 

Upon connection, this local database 172 is automatically 
manipulated by the FL server 132. The FL server 132 can 
query the client database 172, add data to the client 
database, or remove data from the client database in order 
make updates to both the client and server databases to 
reflect changes that have happened on both sides since the 
last connection. 

Wright does not expressly disclose the mobile data model ... capable of 

independently describing key details required by a client-side application; However, in 

an analogous environment, Bowman- Amuah teaches that a streamed model can be 

described using meta-data. See Bowman- Amuah column 237 lines 7-13: 

In cases like this, it would be better to implement a communication mechanism or 
"shared format" that can better handle changes to the systems. 



Application/Control Number: 09/848,770 p age 17 

Art Unit: 2192 

Therefore, use a Self-Describing Stream and create a stream that contains message data 
AND descriptive meta-data. Then use a message language to read the formatting 
information and meta-data off of the stream 

This "Self-Describing Stream" enables changes to a system without requiring 
programmatic changes since the stream provides all the details regarding its contents 
through descriptive meta-data. It would have been obvious to one of ordinary skill in the 
art at the time the invention was made to use Bowman- Amuah's teaching of a self- 
describing stream with Wadhwa's independent data model. One of ordinary skill would 
have been motivated to use a shared format that permits the efficient handling of changes 
to the system (Bowman- Amuah column 237 lines 7-9), 

All further limitations have been addressed in the above rejection of claim 1. 

As per claim 23, the above rejection of claim 22 is incorporated. Wright further 
discloses: deriving a first mobile data model from an enterprise information system; and 
modifying the first mobile data model to yield the deploy able mobile data model (column 
4 lines 38-43). 

As per claim 24, Wright discloses: 

A method for application development and deployment (column 6 lines 34-38: 

The FL Builder (not shown) is a development tool, previously described in applicant's 
copending patent application, now U.S. Pat. No. 5,704,029, used to build FormLogic 
applications that can be executed on a variety of hardware platforms. 

adding at least a portion of the mobile data model to a package Developing a 
mobile data model is inherent to adding it to a package, otherwise there would be nothing 
to add; see column 6 lines 63-64: 
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Communications agents, also just known as "agents", are developed to describe the 
communications "session". Communications agents know how to connect to a particular 
host, perform a set of operations or tasks, which usually includes synchronizing the 
host data source, e.g., 180, with the client database 172, and then disconnecting. The 
idea is that a developer can create a communications agent that represents each of the 
communications sessions that a field user may need. 

Here, the mobile data model is evidenced by the set of operations that make up an agent. 

An agent here is considered to be equivalent to a package. In order for the agent to 

operate on the host data source, it must inherently use a data model, otherwise it would 

not be able to find or distinguish the data contained therein. 

including the package in a mobile user application column 7 lines 21-23: 

An exemplary Sessionl 200 called Daily Connect includes three tasks: Taskl 204, e.g., 
GetMail; Task2 206, e.g., SendMail; and Task3 208, e.g., Updatelnventory. 

deploying the mobile user application to a distributed computing device See 
column 4 lines 2-4 as cited above in the rejection of claim 1 1. 

All further limitations have been addressed in the above rejection of claim 1 . 

As per claim 25, the above rejection of claim 24 is incorporated. Wright further 
discloses: including at least an integration portion of the mobile data model in an 
application comprising an integration component (column 6 lines 49-56; An integration 
component in inherent to a the "retrieve work order" session described in this passage. 
Without an integration component, a new work order would not be able to be examined.). 

As per claim 26, the above rejection of claim 24 is incorporated. Wright further 
discloses: wherein the mobile user application is operable to colonize the distributed 
computing device and initiate the instantiation of a data store on the distributed 
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computing device, the instantiation described by the at least a portion of the mobile data 
model added to the package (column 4 lines 38-43). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to J. Derek Rutten whose telephone number is (571) 272-3703. The 
examiner can normally be reached on T-F 6:00 - 4:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on (571) 272-3695. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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